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Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

The present document is part 6 sub-part 2, of a multi-part deliverable covering Broadcast and On-line Services: Search, 
select and rightful use of content on personal storage systems ("TV- Any time Phase 1"), as identified below: 

Part 1: "Phase 1 Benchmark Features"; 

Part 2: "System description"; 

Part 3: "Metadata"; 

Part 4: "Content referencing"; 

Part 5: Not currently applicable in TV- Anytime Phase 1; 

Part 6: "Delivery of metadata over a bi-directional network"; 

Sub-part 1: "Service and transport"; 

Sub-part 2: "Service discovery"; 
Part 7: "Bi-directional metadata delivery protection". 



Introduction 

The present document document is based on a submission by the TV-Anytime forum ( http://www.TV-Anytime.org ). 

'TV -Anytime Phase 1' (TVA-1) is the first full and synchronized set of specifications established by the TV-Anytime 
Forum. TVA-1 features enable the search, selection, acquisition and rightful use of content on local and/or remote 
personal storage systems from both broadcast and online services. 

The features are supported and enabled by the specifications for Metadata, Content Referencing, and Bi-directional 
Metadata Delivery Protection, TS 102 822-3 sub-parts 1 [12] and 2 [13], TS 102 822-4 [14], TS 102 822-6-1 [15] and 
TS 102 822-7 [16] respectively. All Phase 1 Features listed in TV035r6 are enabled by the normative TV-Anytime tools 
specifications. This list of Phase 1 Features is to be used as guidance to manufacturers, service providers and content 
providers regarding the implementation of the Phase 1 TV-Anytime specifications. 
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Scope 



The present document is the sixth in a series of "S-series" specification documents produced by the TV-Anytime Forum. 
These documents establish the fundamental specifications for the services, systems and devices that will conform to the 
TV-Anytime standard, to a level of detail that is implementable for compliant products and services. 

As is common practice in such standardization efforts, these specification documents were preceded by requirements 
documents ("R-series"), which define the requirements for the TV-Anytime services, systems, and devices. 

Congruent with the structure defined in the initial TV-Anytime Call for Contributions (TV014r3), these specifications 
are parsed into three major areas: Metadata, Content Referencing, and Rights Management and Protection. Within these 
general areas, four specifications have been developed to date: TS 102 822-3 sub-parts 1 [12] and 2 [13], 
TS 102 822-4 [14], TS 102 822-6 sub-parts 1 [15] and 2 (the present document) and TS 102 822-7 [16]. A specification 
for TS 102 822-5 is still under development. See the several TV-Anytime Calls for Contributions for more detail on the 
derivation and background of these categories and their respective roles in the TV-Anytime standardization process. 

The first two documents in the TV-Anytime S-series are intended to define the context and system architecture in which 
the standards in TS 102 822-3-1 [12], TS 102 822-3-2 [13], TS 102 822-4 [14], TS 102 822-6-1 [15], TS 102 822-6-2 
(the present document) and TS 102 822-7 [16] are to be implemented in "Phase 1" of the TV-Anytime environment. The 
first document in the series (TS 102 822-1 [25]) provides benchmark business models against which the TV-Anytime 
system architecture is evaluated to ensure that the specification enable key business applications. The next document in 
the series (TS 102 822-2 [11]) presents the TV-Anytime System Architecture. These two documents are placed ahead of 
the other three for their obvious introductory value. (Note that TS 102 822-1 [25] and TS 102 822-2 [11] are largely 
informative documents, while the remainder of the S-series is normative. Also note that a "Phase 2" of the TV-Anytime 
process is currently underway, in which additional requirements and specifications that will build on Phase 1 are being 
developed. Readers are encouraged to check the TV-Anytime Forum's website at www.TV-Anytime.org for the most 
recent status of its specifications.) 

Although each of the S-series documents is intended to stand alone, a complete and coherent sense of the TV-Anytime 
system standard can be gathered by reading all of the Phase 1 specification documents in numerical order. 

The scope of the present document, comprises the delivery of TV-Anytime metadata and content referencing information 
via a bi-directional network using a PDR's return path. 

The requirements for this technology are outlined in the TV-Anytime Forum's Requirement Series R-l document [10]. 
The following paragraphs from those requirements give an overview of the return path's use. 

"The consumer can get more information about the programme from either the content provider or from a programme 
information service offered by a third party. This could include programme specifications (such as source, duration, 
format, storage location, etc.), programme schedules, commentary, critiques, liner notes from the provider or third 
parties, etc." 

"A Return Path is a data connection from a consumer's home digital storage system (e.g. PDR) to one or more service 
providers. The return path gives the consumer access to interactive content, such as the Internet and interactive 
television. It also allows service providers to access consumer profile/preference information in order to make business 
decisions regarding content that is provided to the consumer." 

The present document describes a client-initiated means for requesting metadata from, and submitting user-centric data 
to, IP based web services. In the present document, these web services are termed "metadata services". The 
specification also defines a means for describing and discovering such metadata services, but does not address the 
unidirectional delivery of metadata over IP networks, or the delivery of content over IP networks. A more complete 
definition of the scope of this work, along with the system requirements, may be found in document TV 150, 
"Requirements and scenarios for the bi-directional transport of metadata" [3]. 
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Definitions, abbreviations and conformance 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

acquisition: retrieval of content 

application: specific set of functions running on the PDR. Some applications use metadata, either automatically or 
under consumer control 

authority: organization that creates CRIDs 

bi-directional network: network that supports two way, point-to-point, one-to-many, and many-to-many data delivery 

NOTE: The Internet is an example of such a network. A PDR may access a bi-directional network using its return 
path. 
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capture: storing the acquired content (e.g. to local storage) 

content: anything the viewer would like to access (movies, games, TV programmes, radio programmes, etc.) 

content creator: producers of the content 

content provider: entity that acts as the agent for and is the prime exploiter of the content 

content reference: pointer to a specific content item 

location resolution: process of establishing the address (location and time) of a specific content instance from its CRID 
locator: time and place where a content item can be acquired 

metadata: generally, data about content, such as the title, genre, and summary of a television programme 
NOTE: In the context of TV-Anytime, metadata also includes consumer profile and history data. 

metadata service: service that provides TV-Anytime data using a server on a bi-directional network 

NOTE: The formats of the data and the protocols used to deliver that data are defined by the present document. 

programme: editorially coherent piece of content 

NOTE: Typically, a programme is acquired by the PDR as a whole. 

resolving authority: body which provides location resolution 

Resolving Authority Record (RAR): information needed for retrieving the location resolution data for the given 
authority 

return path: part of the bi-directional distribution system from the consumer to service provider 

segment: continuous portion of a piece of content, for example a single news topic in a news programme 
service provider: aggregator and supplier of content which may include gateway and management roles 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ARIB Association of Radio Industries and Businesses 

NOTE: A Japanese standards organization 

ATSC Advanced Television Systems Committee 

NOTE: American based standards organization for establishing technical standards for advanced television 
systems, including digital high definition television. 

BiM Binary format for multimedia description streams 

NOTE: Defined in ISO/IEC 15938-1 [26] (MPEG-7 Systems part). 



CE 

CRID 



Consumer Electronics 
Content Reference Identifier 



NOTE: Identifier for content that is independent of its location. 

DNS Domain Naming System 

NOTE: System used on the Internet to register names that can then be mapped into IP addresses using a DNS 
server RFC 1591 [4]. 

DVB Digital Video Broadcasting 

NOTE: Set of standards used for European digital TV broadcasting. 
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EPG Electronic Programme Guide 

NOTE: Means of presenting available content to the consumer, allowing selection of desired content. 



HTTP 
IP 



HyperText Transfer Protocol 
Internet Protocol 



NOTE: Generic name for the network protocols used on the Internet. 



IPR 
PDR 
RAR 
SI 



Intellectual Property Rights 
Personal Digital Recorder 
Resolving Authority Record 
System Information 



NOTE: Collection of information tables used in DVB. 

SOAP Simple Object Access Protocol 

SQL Structured Query Language 

TCP Transmission Control Protocol 

UDDI Universal Description Discovery and Integration 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

VOD Video On Demand 

W3C World Wide Web Consortium 

WSDL Web Services Description Language 

WS-Inspection Web Services Inspection language 

XML Extensible Markup Language 

3.3 Conformance 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "MAY", and "OPTIONAL" in the present document are to be interpreted as described in 
RFC 21 19 [6]. 

It is important to note that OPTIONAL and RECOMMENDED elements of the specification, if they are implemented, 
MUST be implemented in the manner documented in the present document. 



4 Introduction 

The TV-Anytime Forum has defined a number of data types that can be exchanged between TV-Anytime devices. These 
include programme metadata, content referencing information, and user-centric metadata. The present document is 
concerned with data exchange between TV-Anytime clients and metadata servers over a bi-directional network using the 
return path. A TV-Anytime client is typically a PDR, although in the present document the client can be any Internet 
connected device. These devices do not necessarily need to have the ability to display or store content, since many types 
of devices can exploit TV-Anytime metadata services (e.g. a mobile phone displaying an EPG). 

Programme metadata and content referencing information can be delivered unidirectionally (e.g. via traditional 
broadcast or IP multicast) or via a bi-directional network. The reasons a TV-Anytime provider might choose to deliver 
data via a bi-directional network are as follows: 

• It allows a richer set of metadata to be delivered, since there are much lower bandwidth constraints. 

• It allows TV-Anytime data providers without access to a broadcast system to deliver metadata to clients. 

• It allows TV-Anytime data providers to personalize the metadata they offer according to the source of the 
request. 

• It allows a range of client devices, which are not necessarily able to receive broadcast data, to access and 
exploit TV-Anytime data. For example, a mobile phone or personal organizer could use the metadata service to 
show the user an EPG. 



ETSI 



10 



ETSI TS 102 822-6-2 V1.1.1 (2003-10) 



User-centric metadata can only be delivered from a PDR to a TV-Anytime metadata service when a return path is 
available and the user authorizes it. The submission of such user data allows the metadata service to provide a variety of 
value adding services, which are more completely described in clause 6.5 of TS 102 822-3-1 [12]. 

The present document defines the protocols that allow these transactions to take place in an interoperable fashion. Note 
that, due to the widespread nature and mass penetration of the Internet, the TV-Anytime Forum has completely specified 
the transport and network layer protocols (TCP/IP) necessary for end-to-end interoperability. This is in contrast to 
unidirectional transport mechanisms, which are not completely specified by the TV-Anytime Forum, but instead defined 
individually by the bodies responsible for the various broadcast standards used around the world (e.g. ARIB, ATSC, 
DVB, etc.). 

To use a TV-Anytime metadata service a client takes the steps illustrated in figure 1 . 




Discover 

Metadata 

Service 



Obtain 
Capability 
Description 



Exploit 

Metadata 

Service 




URL 



Metadata Service 
Capability Description 



Figure 1 : The steps in using a TV-Anytime metadata service 

These steps are described in more detail in the following three clauses (in reverse order). Note that a metadata service 
MUST provide a description capability (see TS 102 822-6-1 [15]) but the support for metadata service discovery (the 
present document) is OPTIONAL. The middle step typically will only occur when a metadata service is first discovered 
or updated, and not each time the metadata service is used. 

4.1 Types and Functionalities of Metadata Services 

TV-Anytime metadata services can be broken into two basic types, which are shown in figure 2 and figure 3. The 
metadata services specified are all request-response based. This can be seen in the two figures - the network transaction 
is always point-to-point (client to server), and the transaction is always initiated by the client. 



4.1.1 



Metadata Retrieval 



Metadata retrieval occurs when a client wishes to obtain certain metadata from a metadata service that it has previously 
discovered and obtained a capability description for. The following list gives some examples of metadata retrieval. 

• A client wishes to obtain programme reviews for a CRID. The client sends a request specifying the CRID and 
type of metadata required, and the metadata service responds with the appropriate ProgramReviewTable. 

• A client wishes to obtain the schedule information for a particular channel over the next week. The client 
sends a request specifying the channel, date range, and type of metadata required. The metadata service returns 
a ProgramLocationTable and Programlnf ormationTable corresponding to the programmes on 
that channel. 

• A client wishes to search a metadata service that specializes in movie information. The client sends a request 
specifying the type of movie (e.g. the genre is "Western", and the star is "John Wayne"), and the type of 
metadata required. The metadata service returns a number of matching movies, using a 
Programlnf ormationTable and ProgramReviewTable. 
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Metadata 
Service 



IP Network 



Request 




Metadata 



NOTE 1 : Any party capable of delivering compliant TV-Anytime data could provide a metadata service. Examples 

include: content creators, content providers, service providers, consumer electronics manufacturers and 

third parties aggregation services. 
NOTE 2: The request contains parameters that specify the type of metadata required by the client. 
NOTE 3: The types of metadata returned could be any of the non user-centric data specified in TS 102 822-3-1 [12] 

(i.e. the fragments defined in clause 4.3.1 .1 of TS 1 02 822-3-2 [1 3]), along with content referencing 

information. 

Figure 2: Client requesting metadata from a metadata service 

4.1 .2 Submission of User-centric Metadata 

Submission of user-centric metadata offers a number of possible benefits to both consumers and metadata service 
providers. These are described in clause 5 of TS 102 822-3-1 [12]. Ensuring the privacy of these transactions and that 
the metadata service provider is trustworthy is essential to the submission of user-centric metadata. The means by which 
this is ensured is not defined by the present document. 
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IP Network 



User-centric data 




Acknowledgement 



NOTE 1 : In this case, the metadata service is a user data aggregator. Any of the parties listed for figure 2, or any 
other party capable of usefully exploiting TV-Anytime usage information in a trustworthy fashion, could 
provide the metadata service. 

NOTE 2: In principle, the user-centric data may be any of the types defined in TS 102 822-3-1 [12] 

(e.g. userPref erences and usageHistory). For the purposes of this version of the specification, only 
a submission of carefully constrained, anonymous UsageHistory instances is allowed. 

Figure 3: Client submitting user-centric data to a service provider 

4.2 Metadata Service Capability Descriptions 

In order to exploit usefully the metadata services described in the previous clause, the client needs information about the 
nature of the metadata service being offered. This is because different metadata services will provide different types of 
metadata and can be queried in different ways. For example, some metadata services may offer just content referencing 
information, whilst others may provide programme metadata but no segmentation information. Similarly, whereas one 
server may only be able to accept simple requests for metadata based on a CRID, another server may offer much more 
sophisticated querying and sorting capabilities. Moreover, different types of queries are only useful if a client is able to 
establish sensible values with which to query. An example of this is a query for scheduling data 
(ProgramLocationTable). In order to query for scheduling information on a particular content delivery service, 
the client needs to know the content delivery services for which that metadata service has data. 

To address this issue, each metadata service provides, on request from a client, a capability description. This capability 
description allows a client to flexibly query a metadata service, without making requests that will not be supported by 
that metadata service. Furthermore, it allows metadata service providers to flexibly implement the server in a way that 
is appropriate to the data that they have available. 



4.3 Metadata Service Discovery 



Metadata service discovery is the process by which a client establishes a URL where a TV-Anytime metadata service 
can be found. There are a number of ways this process can occur, but only the third method (see clause 4.3.3) is 
addressed by the present document. 

4.3.1 Non-standardized Discovery 

A number of methods exist for discovering the URLs of metadata services that will not be standardized by the 
TV-Anytime Forum. The following list gives some examples. 

• The client might be pre-programmed with a set of URLs that refer to one or more metadata services. This will 
typically be useful in a vertical market, or tightly controlled horizontal market. 
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• A user might manually enter a URL of a new metadata service he is interested in, using some means of text 
input. 



• 



The software on a client may be updated using software updates delivered via a unidirectional broadcast, or 
over the return channel. 



4.3.2 Unidirectional Delivery of Discovery Information 

The System Specification [17], and Content Referencing Specification, [14] define ways, or requirements on the 
underlying transport, in which the URL of a bi-directional metadata and/or content referencing service can be 
discovered from TV-Anytime information inserted in a unidirectional stream. The present document defines how a client 
can usefully exploit the discovered service using the resulting URL. 

4.3.3 Client-Initiated Discovery Using the Bi-directional Network 

This mode of metadata service discovery involves using the bi-directional network to access a "Yellow Pages" of 
TV-Anytime metadata services. The mechanism is based upon W3C standards for web service discovery (UDDI [21] 
and WS -Inspection [21]), the use of which is standardized by the TV-Anytime Forum, according to the rules given in 
clause 5. Support for these discovery techniques by clients and servers is OPTIONAL. 



Metadata Service Discovery 



The present document describes how standard web service discovery techniques can be used to allow PDRs and other 
TV-Anytime clients to discover TV-Anytime metadata services. The relevant standards are UDDI [19] and 
WS-Inspection [21], which enable different, but complementary, modes of discovery. A provider can choose to enable 
neither, both, or just one of these mechanisms. 

For a useful overview of these two standards please refer to: "The WS-Inspection [21] and UDDI Relationship" [19]. 

5.1 Discovering a get_Data operation that will provide metadata 
for a certain CRID authority 

The content referencing specification describes the use of DNS SRV records to discover web services for location 
resolution, using only a CRID as the starting point. The present document defines an analogous method for use in 
discovering metadata delivery services. The form of the DNS query string is: 

_gmet._tcp.<name_extension segment from CRID authority >.<DNS segment from CRID authority>, 

where gmet is short for "get metadata". 

Since a resolution authority will not necessarily provide (directly or indirectly) a metadata service for its CRIDs, the 
client SHOULD NOT assume that this DNS enquiry will succeed. The result of the DNS query is a machine name 
(<hostname>) and port (<port>) that locates the metadata server. A get_Data service capable of returning at least 
one type of metadata table is offered at this URL (http://<hostname>:<port>/). 

5.2 Universal Description, Discovery and Integration (UDDI) 

UDDI [19] allows PDRs, and other clients with Internet connectivity, to discover TV-Anytime metadata services without 
the client requiring any prior knowledge of the metadata service, nor any information from a unidirectional metadata 
service. Metadata service providers may publish details of their TV-Anytime metadata service(s) to the UDDI Business 
Registry. Any client can then use a node in the UDDI Business Registry (which have well-known addresses) to browse 
and locate TV-Anytime metadata services. 

Note that version 3 of the UDDI specification is used. Clients wishing to discover TV-Anytime web services using 
UDDI must conform to the behaviour described in the UDDI specification [19]. To assist metadata service providers in 
describing and categorizing their services, the TV-Anytime Forum has registered the UDDI tModels described in the 
following clauses (see clause 1.6.4 of the UDDI specification [19] for a definition of "tModel"). 
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5.2.1 TV-Anytime web service tModels 

These tModels are used when a business publishes details of their bindingTemplate structures to indicate a web 
service compliant with the present document. Clients issuing UDDI inquiry requests can use these two tModel keys 
to find only web services that are TV-Anytime metadata services. 

5.2.1.1 TV-Anytime get_Data port tModel 

This technical model represents a get_Data port as described in clause 5.1. 
Name: TV-Anytime-org:get_Data_vlO 

Description: TV-Anytime WSDL interface for get_Data port 

UDDI Key (V3): uddi:TV-Anytime.org:get_Data_vlO 

Categorization: specification, xmlSpec, soapSpec, wsdlSpec 



<tModel tModelKey="uddi : TV-Anytime . org : get_Data_vlO "> 
<name>TV-Anytime-org : get_Data_vlO</name> 

<description xml : lang="en">TV-Anytime WSDL interface for get_Data port</description> 
<overviewDoc> 

<overviewURL useType="text "> 

FIXME: location of ETSI spec TS 102 822-6-1 via http or ftp 
</overviewURL> 
</overviewDoc> 
<overviewDoc> 

<overviewURL useType="text "> 

ftp : //tva : tva@ftp . bbc . co .uk /pub /Specif ications/SP006vlO .zip 
</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org: types :wsdl" keyValue="wsdlSpec" 

tModelKey="uddi : uddi .org:categorization: types" /> 
<keyedRef erence keyName="uddi-org : types : soap" keyValue=" soapSpec" 

tModelKey="uddi : uddi .org: categorization: types" /> 
<keyedRef erence keyName=" uddi -org : types : xml" keyValue=" xml Spec" 

tModelKey="uddi : uddi .org:categorization: types" /> 
<keyedRef erence keyName="uddi-org : types : specification" 
keyValue=" specification" tModelKey="uddi : uddi . org : categorization : types "/> 
</categoryBag> 
</tModel> 



5.2.1 .2 TV-Anytime submit_Data port tModel 

This technical model represents a submit_Data service as described in clause 5.2. 
Name: TV-Anytime-org:submit_Data_vlO 

Description: TV-Anytime WSDL interface for submit_Data port 

UDDI Key (V3): uddi:TV-Anytime.org:submit_Data_vlO 

Categorization: specification, xmlSpec, soapSpec, wsdlSpec 



<tModel tModelKey=' 


uddi 


: TV-Anytime . org : submit. 


_Data_ 


vlO 


■> 












<name>TV-Anytime- 
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<description xml: 


lang 
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<overviewDoc> 
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<overviewURL useType="text "> 

ftp : //tva : tva@ftp . bbc . co . uk/pub/ Specif icat ions/ SP006vlO .zip 
</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org : types : wsdl" keyValue="wsdlSpec" 

tModelKey="uddi : uddi .org:categorization: types "/> 
<keyedRef erence keyName="uddi-org: types : soap" keyValue="soapSpec" 

tModelKey="uddi : uddi . org : categorization : types " /> 
<keyedRef erence keyName=" uddi -org : types : xml" keyValue="xmlSpec" 

tModelKey="uddi : uddi . org : categorization : types " /> 
<keyedRef erence keyName="uddi-org : types : specification" 
keyValue=" specif icat ion" tModelKey="uddi : uddi .org:categorization: types "/> 
</categoryBag> 
</tModel> 



5.2.2 TV-Anytime categorization tModels 



These tModels allow a metadata service provider to categorize their services. The metadata service provider assigns 
the categories at the point of publication (see clause 5.2.3). This enables clients to issue more refined UDDI searches for 
metadata services. By categorizing a metadata service as richly and accurately as possible, a metadata service provider 
maximizes the possibility of the metadata service being discovered using UDDI. 

Use of these taxonomies is OPTIONAL, and for many services it will not be appropriate to use some of the taxonomy 
types. For example, a metadata service that does not provide schedule information will not be able to use the 
TV-Anytime-org : serviceURL taxonomy to list the services for which it provides metadata. 

These taxonomies do not make strong guarantees about the behaviour of any services that use them. For example, a 
service categorized as providing information on "example.com" CRIDs may only have data on some subset of them. A 
get_Data request to that service could fail to provide information on a particular "example.com" CRID. Similarly, a 
service categorized as providing German language metadata could return some of its metadata in other languages. 
Metadata service providers should sensibly categorize their services in a way that will enhance their discovery without 
creating false expectations in the client. It is always the capability description that provides the definitive description of 
the features supported by a particular operation. Therefore, having discovered a metadata service, a client SHOULD 
always retrieve a capability description of that service (see clause 7). In some cases, this involves no extra steps as the 
capability description will be included inside the bindingTemplate for that operation (as recommended in 
clause 13.2.3). 

All of the following tModels are categorization tModels and are unchecked. 

5.2.2.1 TV-Anytime authorityName Categorization System 

The authorityName tModel is used to represent the resolution authorities of the CRIDs for which this metadata 
service provides TV-Anytime information. To establish whether content referencing information or metadata is available 
for the authority, the tableType tModel may be used (see clause 5.2.2.2). 

Name: TV-Anytime-org: authorityName 

Description: Category system for the resolution authorities handled by a metadata service. 

UDDI Key (V3): uddi:TV-Anytime.org:authorityName 

Valid values: A valid value is a valid resolution authority name, as defined in the Content Referencing 

Specification [14]. 

Example usage: A client searches for TV-Anytime metadata on CRIDs from a particular resolution authority. 

<tModel tModelKey="uddi : TV-Anytime . org: authorityName"> 
<name>TV-Anytime-org : authorityName</name> 

<description xml : lang="en">Category system for the resolution authorities handled by 
a metadata service</description> 
<overviewDoc> 

<overviewURL useType="text "> 
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ftp : //tva : tva@ftp .bbc . co .uk /pub /Specif ications/SP00 6vlO .zip 
</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org : types : categorization" 
keyValue=" categorization" tModelKey="uddi : uddi .org:categorization: types "/> 

<keyedRef erence keyName="uddi-org : types : unchecked" 
keyValue=" unchecked" tModelKey="uddi : uddi .org: categorization: types" /> 

</categoryBag> 
</tModel> 



5.2.2.2 TV-Anytime tableType Categorization System 

The tableType tModel is used to represent the types of metadata table that this metadata service is capable of 
providing. 

Name: TV-Anytime-org:tableType 

Description: Category system for the metadata table types available from a metadata service. 

UDDI Key (V3): uddi:TV-Anytime.org:tableType 

Valid values: A valid value is a table type that can be used in the AvailableTables element (see 

clause 7.1.2) returned by the describe_get_Data operation. 

Example usage: A client requires a certain type of metadata (e.g. segmentation information) about a programme. 



<tModel tModelKey="uddi: TV-Anytime. org :tableType"> 
<name>TV-Anytime-org : tableType</name> 

<description xml : lang="en">Category system for the metadata table types available 
from a metadata service</description> 
<overviewDoc> 

<overviewURL useType="text "> 

ftp : //tva : tva @ ftp .bbc . co . uk/pub/ Specif icat ions/ SP006vlO .zip 
</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org : types : categorization" 
key Value=" categorization" tModelKey="uddi : uddi .org:categorization: types "/> 

<keyedRef erence keyName="uddi-org : types : unchecked" 
keyValue=" unchecked" tModelKey="uddi : uddi . org : categorization : types" /> 

</categoryBag> 
</tModel> 



5.2.2.3 TV-Anytime serviceURL Categorization System 

The serviceURL tModel is used to represent the content delivery services (e.g. channels) for which this metadata 
service provides TV-Anytime information. 

Name: TV-Anytime-oig: serviceURL 

Description: Category system for the content services handled by a metadata service. 

UDDI Key (V3): uddi:TV-Anytime.org:serviceURL 

Valid values: A valid value MUST comply with the rules defined in TS 102 822-3-1 [12] for the 

serviceURL element in the ServicelnformationTable. 

Example usage: A client searches for TV-Anytime scheduling information on a particular content service. 



<tModel tModelKey= 
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<overviewDoc> 

<overviewURL useType="text "> 

ftp : //tva : tva@ftp .bbc . co .uk /pub /Specif ications/SP00 6vlO .zip 
</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org : types : categorization" 
keyValue=" categorization" tModelKey="uddi : uddi .org:categorization: types "/> 

<keyedRef erence keyName="uddi-org : types : unchecked" 
keyValue=" unchecked" tModelKey="uddi : uddi .org: categorization: types" /> 

</categoryBag> 
</tModel> 



5.2.2.4 TV-Anytime genre Categorization System 

The genre tModel is used to broadly classify the types of programmes for which this metadata service provides 
TV-Anytime information. This tModel is intended to classify metadata services providing specialist information, and 
will not be useful for metadata services that describe a wide range of programme types (e.g. broadcasters' metadata 
services). 

Name: TV-Anytime-org:genre. 

Description: Category system for the genre of programmes handled by a metadata service. 

UDDI Key (V3): uddi:TV -Anytime. org:genre. 

Valid values: A valid value is a fully qualified term (classification scheme URN and term), as defined in 

annex B of TS 102 822-3-1 [12]. Note that aliases cannot be used since a UDDI registry has no 
knowledge of any CSAlias elements from which the full classification scheme name can be 
deduced. 

Example usage: A client searches for a TV-Anytime metadata service that specializes in movie information. 

<tModel tModelKey="uddi : TV-Anytime . org : genre"> 
<name>TV-Anytime-org : genre</name> 

<description xml : lang="en">Category system for the genre of programme handled by a 
metadata service</description> 
<overviewDoc> 

<overviewURL useType="text "> 

ftp : //tva : tva@ftp .bbc . co .uk /pub /Specif ications/SP00 6vlO .zip 
</overviewURL> 
</overviewDoc> 
<categoryBag> 

<keyedRef erence keyName="uddi-org : types : categorization" 
keyValue=" categorization" tModelKey="uddi : uddi .org:categorization: types "/> 

<keyedRef erence keyName="uddi-org : types : unchecked" 
keyValue=" unchecked" tModelKey="uddi : uddi .org:categorization: types" /> 

</categoryBag> 
</tModel> 



5.2.2.5 Other categorizations 

The Universal Business Registry provides other categorizations that may be useful in describing TV-Anytime metadata 
services (e.g. uddi-org:general_key words). The use of such categorizations should, in general, follow the rules defined 
by the particular tModel, but TV-Anytime provides guidance for use of the 

uddi:ubr.uddi.org:categorization:geo3166-2 tModel. Namely, the assigned keyValue SHOULD categorize the 
region(s) where the programmes described by that metadata service are available. For some types of content distribution 
mechanisms (e.g. via the Internet) such a categorization will not be appropriate. 

Categories may be grouped together, as described in clause F.2 of the UDDI specification [20]. 
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5.2.3 Publishing a TV-Anytime metadata service 

A TV-Anytime metadata service provider can publish details of their service to any node in the UDDI Business Registry. 
The manner in which this is done will depend upon the operator of that node (see the UDDI specification [20]). 

An example of the publication process can be found in annex A. 

A businessService is created for each metadata service that needs to be registered by that business. The 
businessService element contains a bindingTemplate for each of the bindings offered by that metadata 
service (e.g. get_Data or submit_Data). 

When publishing a get_Data operation, it is RECOMMENDED that: the instanceParms element (inside the 
tModellnstancelnf o) contains a capability description. This allows the client to acquire the capability description 
of the metadata service (and so determine its usefulness), without having to issue a describe_X request. Since the 
size of the instanceParms element is restricted, the capability description will sometimes need truncating, in which 
case the capability description MUST remain schema valid. 

5.3 Web Services Inspection Language (WS-lnspection) 

A TV-Anytime web server may declare the presence of its metadata services using WS-lnspection [21]. This allows 
clients to discover service descriptions (i.e. WSDL implementation definitions) for the web services available on that 
website. The WS-lnspection file may also lead to the discovery of other types of web services, as well as TV-Anytime 
metadata services available on other web sites. 

It is RECOMMENDED that each description element use a WSDL extensibility reference in the following 
fashion: 

• The endpointPresent attribute SHOULD be set to "true" (since a client is looking for existing services, 
and not abstract service definitions). 

• An implementedBinding element SHOULD be included for each port Type offered by the 
TV-Anytime service. In this way, the client can establish whether the corresponding service actually offers 
TV-Anytime ports and, if so, which port Types are present, without having to download and parse the 
WSDL implementation description. 

An example WS-lnspection file, along with its corresponding WSDL implementation definition, can be found in 
annex B. 

5.3.1 Discovering the WS-lnspection file 

To assist a client in finding a WS-lnspection file, clause 6.1 the WS-lnspection specification states that the document 
may have a well-known name (inspection. wsil) and be placed at a "common entry point" of the web-site. The term 
"common entry point" is vague, so TV-Anytime defines the following rules to make it easier for embedded clients to 
retrieve the WS-lnspection document. 

• A metadata service provided by a web server with machine name <hostname>, which wishes to provide a 
WS-lnspection file, SHOULD place the document at the root of its web server. Thus, an HTTP GET request to 
http://<hostname>/inspection.wsil will retrieve the file if it exists. 

• A resolution authority with the name <domain_name>;<extension_name>, which wishes to provide a 
WS-lnspection file, SHOULD place the document at the location 

http://<domain_name>/<extension_name>/inspection.wsil. Note that this does not necessarily mean that the 
web server with the same domain name as the resolution authority has to also provide the metadata service 
since it is possible that the WS-lnspection document points to a URL on a different server. 
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Annex A (informative): 
Example Usage of UDDI 

A.1 Example Publication of get_Data Operation 

The metadata service provider registers the new operation using the UDDI save_binding publication API 
(assuming that the appropriate parent businessEntity and business Service structures have already been 
registered). 

<save_binding xmlns="urn : uddi-org : api_v3"> 
<bindingTemplate> 

<description xml : lang="en">TV-Anytime movie inf ormation</description> 
OccessPoint useType="endPoint "> 

http : //barry-norman . com/movies</accessPoint> 
<tModelInstanceDetails> 

<tModel Instance Info tModelKey="uddi : TV- Any time . org: get_Data_vlO"> 
<instanceDetails> 

<instanceParms>< ! [CDATA[ 

<?xml version=" 1 . 0" encoding="utf-8 " ?> 

<describe_get_Data_Result serviceVersion="3 " 
xmlns="urn : tva :transport:2002"> 
< ! -- etc. See example 3 in Annex D --> 
</describe_get_Data_Result> 
] ] ></instanceParms> 
</instanceDetails> 
</ tMode 1 In stance In fo> 
</tModelInstanceDetails> 
<categoryBag> 

<keyedRef erence tModelKey="uddi : TV-Anytime . org : authorityName" 

keyValue="barry-norman . com" /> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : genre" 

keyValue="urn:tva:metadata:cs :FormatCS : 08-2 002 :3.3"/> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : tableType" 

key Va lue=" Content Re f erencing" /> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : tableType" 

keyValue="ProgramInf ormation" /> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : tableType" 
keyValue="ProgramReview" /> 
</categoryBag> 
</bindingTemplate> 
</save_binding> 

The bindingTemplate structure contains a reference to the tMode 1 for the get_Data operation. In this way, 
the tMode 1 behaves as a technical fingerprint that formally indicates the TV-Anytime compliance of the web service. 

The categorization information allows a client to establish the following: 

• Metadata is provided on CRIDs from the "barry-norman.com" resolution authority. 

• Most of the programmes described by this metadata service have the "movie" genre. 

• The metadata service can return ContentReferencingTable, ProgramlnformationTable, and 
ProgramReviewTable elements. 
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A.2 Example Search for TV-Anytime Metadata Service 

Consider the example of a newly purchased PDR trying to create an enhanced EPG. The PDR wishes to display 
information on a known set of content service URLs (which happen to be DVB locators, obtained from DVB service 
information). To enable the construction of an EPG, the metadata service will need to offer a get_Data operation 
that is capable of delivering at least a ProgramLocationTable and Programlnf ormationTable. The 
following search could be used to find appropriate bindings. 

<f ind_binding xmlns="urn : uddi-org : api_v3"> 
<tModelBag> 

<tModelKey>uddi : TV-Anytime . org : get_Data_vlO</tModelKey> 
</tModelBag> 
< cat e gory Bag> 

<keyedRef erence tModelKey="uddi : TV-Anytime . org : serviceURL" 

keyValue="dvb ://1.2.a"/> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : serviceURL" 

keyValue="dvb ://1.2.b"/> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : serviceURL" 

keyValue="dvb ://1.2.c"/> 
<! — Etc for other DVB locators — > 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : tableType" 

keyValue=" ProgramLocationTable" /> 
<keyedRef erence tModelKey="uddi : TV-Anytime . org : tableType" 
keyValue=" Programlnf ormationTable" /> 
</categoryBag> 
</f ind_binding> 

The data structure returned to the device will contain a list of bindingTemplate elements that satisfy the above 
query. The list can then be refined by the user (based on brand preferences, recommendations, languages used, etc.), or 
automatically by the PDR (based on the capability description, and other taxonomies provided in 
eachbindingTemplate element). 

TV-Anytime clients may also register their interest in a particular type of metadata service, by registering with a node 
using the subscription API (see clause 5.5 of the UDDI specification [20]). In this case, the same f ind_binding 
element above could be used in the subscriptionFilter of the subscription message, thus defining the types of 
services that the PDR is interested in being notified about. 
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Annex B (informative): 

Referencing a WSDL Implementation Description Using 

WS- Inspection 

The following WS-Inspection file contains a reference to a TV-Anytime metadata service providing both a get_Data 
and submit_Data port. 

http://example.com/inspection.wsil 

-(inspection xmlns="http : //schemas . xmlsoap .org/ws/2 001/10/inspection/" 

xmlns : wsdl="http : //schemas . xmlsoap . org/ws/2001/10/inspection/wsdl/ " 
xmlns : tva="urn : tva : transport : wsdl : 2002 "> 
<service> 
<de script ion ref erencedNamespace="http : //schemas . xmlsoap .org/wsdl/" 
location="http : //example . com/TV_week/tva_TV_week . wsdl"> 
<wsdl : reference endpointPresent="true"> 
<wsdl : implementedBinding>tva : get_Data_SOAP</wsdl : implementedBinding> 
<wsdl : implementedBinding>tva : submit_Data_SOAP</wsdl : implementedBinding> 
</wsdl : ref erence> 
</de script ion> 
</service> 
</inspection> 

The location attribute in the above description allows a client to download a WSDL implementation description. 

http://example.com/TV_week/tva_TV_week.wsdl 

< definitions targetNamespace="http : //example . com/ tva" 
xmlns : tva="urn : tva :transport:wsdl:2002" 
xmlns : soap="http : //schemas . xmlsoap . org/ wsdl /soap/ " 
xmlns = "http : //schemas . xmlsoap . org/wsdl/ "> 
< import name space=" urn : tva :transport:wsdl:2002"/> 
<service name="TvaThisWeek"> 

<port name="get_Data_TV_Week" binding="tva : get_Data_SOAP"> 

<soap : address location="http: //example . com/tv_week" /> 
</port> 
<port name="submit_Data_TV_Week" binding="tva : submit_Data_SOAP"> 

<soap : address location="http: //example . com/tv_week" /> 
</port> 
</service> 
</definitions> 



The referenced WSDL implementation definition is simple, and allows a client to establish the URL of the two 
TV-Anytime ports. Also, the technical version of the port is indicated via the namespace of the fully qualified binding 
name. 
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Annex C (informative): 
Bibliography 

Documents are available from the TV- Anytime web site http://www.TV-Anvtime.org . 
"R-l: Call For Contributions" (TV014r3) 
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